Skip to content

Added Snyk Code Parser#9647

Merged
mtesauro merged 7 commits into
DefectDojo:devfrom
FelixHernandez:sc-4509
Mar 1, 2024
Merged

Added Snyk Code Parser#9647
mtesauro merged 7 commits into
DefectDojo:devfrom
FelixHernandez:sc-4509

Conversation

@FelixHernandez
Copy link
Copy Markdown
Contributor

Added Snyk Code Parser

[sc-4509]

Description

A new SnykCodeParser was added and the deduplication is based on ruleID and URI (file_path).
The unittests for this parser were added as well.
#9604

@dryrunsecurity
Copy link
Copy Markdown

dryrunsecurity Bot commented Feb 29, 2024

Contextual Security Analysis

As DryRun Security performs checks, we’ll summarize them here. You can always dive into the detailed results in the section below for checks.

Status DryRun Security Check
Sensitive Functions Analyzer
Configured Sensitive Files Analyzer
Sensitive Files Analyzer

Chat with your AI-powered Security Buddy by typing @dryrunsecurity followed by your question into a comment.
Example: @dryrunsecurity What are common security issues with web application cookies?

Install and configure more repositories at DryRun Security

@github-actions github-actions Bot added the docs label Feb 29, 2024
Comment thread docs/content/en/integrations/parsers/file/snyk_code.md Outdated
Comment thread dojo/tools/snyk_code/parser.py
@manuel-sommer
Copy link
Copy Markdown
Contributor

Hi @grendel513,

I would like to understand why you resolved my review. Could you please comment on that?

Best Regards

@grendel513
Copy link
Copy Markdown
Contributor

Hi @grendel513,

I would like to understand why you resolved my review. Could you please comment on that?

Best Regards

My comment specifically stated why: Keeping this a separate parser is the correct implementation to allow for its own deduplication which is what we are trying to solve for. Additionally having to individual parsers is easier to troubleshoot should issues arise, and has a the benefit of not affecting other tool ingestion if there is something wrong.

Moving forward we will be asking that new parsers be single threaded in function, as having parsers that parse multiple file types creates issues with debugging, deduplication, and the ability to have a separate deduplication configuration.

@grendel513 grendel513 closed this Feb 29, 2024
@grendel513 grendel513 reopened this Feb 29, 2024
@dryrunsecurity
Copy link
Copy Markdown

dryrunsecurity Bot commented Feb 29, 2024

Hi there 👋, @DryRunSecurity here, below is a summary of our analysis and findings.

DryRun Security Status Findings
Sensitive Functions Analyzer 0 findings
Configured Sensitive Files Analyzer 0 findings
Sensitive Files Analyzer 2 findings

Note

🟢 Risk threshold not exceeded.

Tip

Get answers to your security questions. Add a comment in this PR starting with @DryRunSecurity. For example...

@dryrunsecurity What are common security issues with web application cookies?

Powered by DryRun Security

@github-actions github-actions Bot added the settings_changes Needs changes to settings.py based on changes in settings.dist.py included in this PR label Feb 29, 2024
@manuel-sommer
Copy link
Copy Markdown
Contributor

manuel-sommer commented Feb 29, 2024

Hi @grendel513,
I would like to understand why you resolved my review. Could you please comment on that?
Best Regards

My comment specifically stated why: Keeping this a separate parser is the correct implementation to allow for its own deduplication which is what we are trying to solve for. Additionally having to individual parsers is easier to troubleshoot should issues arise, and has a the benefit of not affecting other tool ingestion if there is something wrong.

Moving forward we will be asking that new parsers be single threaded in function, as having parsers that parse multiple file types creates issues with debugging, deduplication, and the ability to have a separate deduplication configuration.

Thank you for clarification. 😄 I understand your logic.
What if we advance the parser structure in a way that file stuctures are automatically recognized (e.g. look at RustyHog) and then deduplication could be implemented for the subfile types (e.g. Deduplication for GottingenHog (RustyHog) etc.)
This whole topic is pretty complicated as there are pros and cons in both directions, but for beginners it would be easier if the number of parsers to be selected within a vendor is limited and the logic within DefectDojo handles the rest.
One way could also be which was implemented in veracode:

  1. entry is a single parser for a vendor
  2. parser recognizes the file type (subscanner)
  3. individual deduplication and scannertype recognition (e.g. like in veracode + rustyhog)

If you (the maintainers) will provide guidelines for the future setup regarding parsers and how to solve the problem the best way, I would like to help here to improve this.

Copy link
Copy Markdown
Contributor

@mtesauro mtesauro left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved

Comment thread docs/content/en/integrations/parsers/file/snyk_code.md Outdated
@mtesauro mtesauro merged commit eb17d85 into DefectDojo:dev Mar 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

docs parser settings_changes Needs changes to settings.py based on changes in settings.dist.py included in this PR unittests

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants